Fix ClaudeSDKClient.receive_response() returning before background agent work finishes - #1224

…ent work finishes

receive_response() stopped on the first ResultMessage it saw, but a result
frame only marks the end of one turn, not necessarily the run: when a
delegated background agent/workflow task is still in flight, the CLI emits
that result to close out the current turn and then continues with a
follow-up turn once the task completes, ending in a second, later
ResultMessage. receive_response() had no way to tell the two apart, so it
returned on the first (intermediate) one and silently missed everything
from the follow-up turn, including the real final result (anthropics#1138).

Query already tracks in-flight delegated agent tasks via
_track_task_lifecycle()/_inflight_tasks (added for anthropics#1088, to avoid closing
stdin too early), so this reuses that same signal: each "result" frame sent
while a delegated task is in flight has its uuid recorded, and
Query.is_deferred_result() lets receive_response() recognize such a frame
and keep reading instead of returning early.

Fixes anthropics#1138.

is_deferred_result() is the only thing that retires an entry from
_deferred_result_ids, and only ClaudeSDKClient.receive_response() calls
it. A caller reading raw frames via receive_messages() instead never
consults it, so a long-lived Query doing many delegated background-agent
turns would accumulate one entry per deferred result for its whole
lifetime.

Cap the set at 128 entries with FIFO eviction, so it self-bounds
regardless of which receive API the caller uses. The real fix for a
given caller is still calling is_deferred_result() (i.e. using
receive_response()); this is a backstop, not a behavior change for
existing receive_response() callers.